This invention generally relates to imaging systems used in medical diagnostics. In particular, the invention relates to the transfer of digital images from an ultrasound imaging system over a network to remote devices for archiving, viewing and/or printing.
Conventional ultrasound imagers create two-dimensional images of biological tissue by scanning a focused ultrasound beam in a scan plane and for each transmitted beam, detecting the ultrasound wave energy returned along a respective scan line in the scan plane. A single scan line (or small localized group of scan lines) is acquired by transmitting focused ultrasound energy at a point, and then receiving the reflected energy over time. A B-mode ultrasound image is composed of multiple image scan lines. The brightness of a pixel on the display screen is based on the intensity of the echo returned from the biological tissue being scanned. The outputs of receive beamformer channels are coherently summed to form a respective pixel intensity value for each sample volume in the scanned object. These pixel intensity values are log-compressed, scan-converted and then displayed as a B-mode image of the anatomy which was scanned.
If the ultrasound probe is swept over an area of body, a succession of image frames (corresponding to spaced slices intersecting the body being examined) can be displayed on the monitor. In one type of ultrasound imaging system, a long sequence of the most recent images are stored and continuously updated automatically in a cine memory on a first-in, first-out basis. The cine memory is like a circular image buffer that runs in the background, capturing image data that is displayed in real time to the user. The cine memory acts as a buffer for transfer of images to digital archival devices via the host computer. When the user freezes the system (by operation of an appropriate device on an operator interface), the user has the capability to view image data previously captured in cine memory. The image loop stored in cine memory can be reviewed on the display monitor via trackball control incorporated in the operator interface, and a section of the image loop can be selected for hard disk storage. Any acquired or projected image can be stored internally on the system hard disk or on a magneto-optical disk (MOD) inserted in a disk drive.
In addition to storing images internally, modern imaging systems need to be able to transfer images to various types of remote devices via a communications network. To successfully transfer images, the relevant networking features of the imager must be compatible with the networking features of the destination remote device. In particular, the imager must place the data to be transferred in a format which can be handled by the destination remote device. An attempt to accomplish the foregoing is the adoption of the DICOM (Digital. Imaging and Communications in Medicine) standards, which specify the conformance requirements for the relevant networking features. The DICOM standards are intended for use in communicating medical digital images among printers, workstations, acquisition modules (such as an ultrasound imaging system) and file servers. The acquisition module is programmed to transfer data in a format which complies with the DICOM standards, while the receiving device is programmed to receive data which has been formatted in compliance with those same DICOM standards.
The DICOM system is based on the client/server concept. The device which uses a service (on objects) is the client device, while the device which provides the service is the server device. The client device is referred to as a Service Class User (SCU), while the server device is referred to as a Service Class Provider (SCP). The SCU sends a Service Request to the SCP over a local area network (LAN). The SCP sends back a response to the SCU over the same LAN. If the response is affirmative and a communications syntax is agreed upon, an association between the SCU and the SCP is opened and data can be transferred between the two devices. In the DICOM system a device is not limited to one role: it can be both SCU and SCP at different times.
The DICOM system is designed to facilitate the communication of digital images of different types, e.g., X-ray, computerized tomography, magnetic resonance and ultrasound imaging. In an ultrasound imager having conventional DICOM capability, three local real-world activities occur: Image Send, Image Print and Remote Verification. Image Send and Image Print can be done in either automatic or manual mode. Verification of remote DICOM devices configured on the ultrasound imager is performed when the imager is powered up or when requested by the system operator.
All DICOM activities are handled in a queued manner by application software running on a host computer incorporated in the imager. In one type of ultrasound imager, the user can select any image in cine memory to be sent in DICOM format via a LAN to a remote device having DICOM capability. The host computer of the ultrasound imaging system is programmed with DICOM system software which facilitates transmission of image frames from the cine memory to the remote DICOM device via the host computer hard disk and the LAN.
In the conventional ultrasound imager, Image Send can be used in automatic or manual mode, depending on the user configuration. When automatic mode is configured, console keys are used to capture the image and to store it on the hard disk. The request is queued to a DICOM queue manager (preferably implemented in software), which requests an association with the destination remote device. After the association with the remote device has been opened, the queue manager xe2x80x9cpushesxe2x80x9d the image to the remote device without user intervention. The transfer is done in the background while scanning or other operator activities continue. In manual mode, the captured images are archived on the hard disk or on a MOD during the exam(s). Upon completion of the exam(s) the images are tagged using an archive menu and queued to any of the network devices that have been configured on the imager. The images are sent sequentially in the background while scanning or other operator activities proceed. Image Print works much the same way as Image Send, in both automatic and manual modes, the only difference being that the destination device is a printer.
In order to accomplish image transfer, the ultrasound imaging system must know the configuration of the destination remote device prior to attempting to communicate with that device. The configuration data for the destination remote device is typically inputted to the ultrasound imager during software installation by a field engineer, although the DICOM network can be configured at any time. When the imager receives an instruction to transmit data to a particular remote device from the system operator, the imager software converts the image data to be transferred into the DICOM format required by the destination remote device, based on the configuration data for that device stored in system memory. The imager also sends a request over the network to the destination remote device to open an association, i.e., to connect the imager to the destination remote device. If the remote device responds in the affirmative, the imager and remote device then agree on which device will act as the server and which as the client. The ultrasound imager also selects the appropriate encoding syntax from those accepted by the remote device. Other communication parameters are also negotiated.
After the DICOM communications protocol has been settled, the association is opened and the imager attempts to send the DICOM-formatted image file (object) to the remote device via the network. The transfer is done in the background while scanning or other operator activities continue. If the remote device is a storage device, each image file is transferred singly in response to a Send request inputted by the operator. If the remote device is a printer configured to print multi-image film, then a number of images are accumulated to make up a multi-image film and an association is opened in response to a Send instruction when a number of images sufficient to fill the multi-image film have been accumulated.
The remote device to which the ultrasound imager sends data can be a printer, a storage device or other device. If the operator interface of the imager has only one configurable Print/Store button, then that button will be configured to initiate data transfer to the destination remote device. The configuration data for the remote device will indicate the type of device to the imager and then the imager will format the data being transferred accordingly. If the operator interface has multiple Print/Store buttons, then each button can be configured to initiate data transfer to a respective remote device. Data transfer to any one of those configured remote devices can then be initiated by pressing the appropriate Print/Store button.
In addition to the digitized image (i.e., pixel data), the DICOM object transferred from the ultrasound imager also includes attribute information. For example, the attribute information may include patient attributes (e.g., patient name and patient identification number), exam attributes (e.g., exam description and exam date), series attributes (e.g., modality type and series date), and image attributes (e.g., image type and numbers of rows and columns). Each attribute has a name, a value representation and a tag. A tag is a number unique to the attribute, e.g., (0040,0100), and is used to identify the attribute. (Different systems use different tags for the same attribute name, which gives rise to incompatibility, as described in more detail hereinafter.) The value representation defines what type of value the attribute can have (e.g., a 64-character string, binary data, etc.).
In accordance with DICOM standards, there are three types of attributes. Type 1 comprises attributes which are mandatory and must always be present with a value; Type 2 comprises attributes which are mandatory but are allowed to be empty; and Type 3 comprises attributes which are optional and are also allowed to be empty. An incompatibility between two devices may arise, for example, if the receiving device requires that a Type 3 attribute be transmitted while the sending device does not include that attribute in its transmission. As a result, even if both devices are configured in accordance with current DICOM standards, the data transfer cannot occur. Thus, even mutual conformance to DICOM standards does not guarantee that two devices can be compatibly connected to each other.
This problem is complicated by the existence of more than one DICOM standard, namely, the DICOM 98 (old) and DICOM 99 (new) standards, having different attribute requirements. Not all existing remote devices can handle the new attribute requirements. The result is that a conventional imaging system is unable to communicate with all remote devices. In particular, the imaging system is able to communicate with remote devices configured to accept the new DICOM attributes, but is unable to communicate with remote devices configured to accept only the old DICOM attributes.
U.S. patent application Ser. No. 09/300,966, filed on Apr. 28, 1999, discloses an imaging system comprising means for turning off or turning on any DICOM attribute to facilitate communication with a particular remote device. This is accomplished by providing an Attribute Control File which is programmable. However, this feature can be utilized only by the few persons who know which DICOM attributes to turn off. The problem is further complicated because some of these attributes are dependent on other attributes and are order sensitive. Therefore, turning one attribute off without turning off an attribute dependent on the first attribute or changing the order of a sequence of attributes can cause even more problems. This complex arrangement of attributes and their dependencies are described in a 14-volume reference set known as the DICOM 3.0 standard. Service people do not have a copy of this reference set and will not get a copy of this set, because it is very expensive and too complex for the service engineer.
Thus there is a need for a method by which an imaging system user can simply configure the attributes which an imaging system will send to a particular remote device without knowing or inquiring which attributes that particular remote device requires.
The present invention is incorporated in an imager which is programmed with at least one DICOM task for constructing objects to be transferred to a remote device. The imager may comprise multiple DICOM tasks for communicating with a respective multiplicity of remote devices. Each DICOM task is configurable by the user to construct objects compatible with a particular remote device, e.g., a storage device or printer. Each configured remote device can then be xe2x80x9cactivatedxe2x80x9d, with the understanding that the term xe2x80x9cactivationxe2x80x9d, as used in this context, means that the imager has a DICOM task configured for that remote device, not that the remote device itself is in any sense remotely activated by the imager.
In accordance with the DICOM standard, each DICOM task is designed to convert an image file, comprising image frame data and attribute data, into a DICOM-formatted object, also comprising image frame and attribute data. That DICOM object must conform not only to the DICOM standards, but also to the attribute requirements (i.e., tags) of the particular remote device destined to receive that DICOM object.
Each Attribute Control File, in ASCII format, is a mapping of which attributes should be included and which attribute tags should be used in every image sent to the remote device associated with that Attribute Control File. Each DICOM task will convert each image file into a DICOM object having the acquired image data from the image file as well as the attribute data dictated by the Attribute Control File associated with that DICOM task. The data for a particular attribute may be taken from either the image file or from the Attribute Control File during construction of the DICOM object by the DICOM task.
In accordance with a further feature of the preferred embodiment, the host computer is programmed with an Attribute Control Engine which controls the inclusion of particular attributes and attribute tags in the DICOM objects constructed by each DICOM task. In particular, in response to queries from a DICOM task, the Attribute Control Engine will instruct that DICOM task concerning which attributes and what attribute tags should be included in the DICOM object being constructed. The Attribute Control Engine in turn obtains that information from the Attribute Control File associated with that DICOM task.
In accordance with the preferred embodiment of the present invention, each DICOM task constructs DICOM objects by incorporating attribute data for tags identified in a selected one of a pair of Attribute Control Files. Each DICOM task has a pair of Attribute Control Files associated therewith. The user can select either one of these two Attribute Control Files, depending on the requirements of the particular remote device to which the image is being transferred, by the simple expedient of operating a switch.
In the preferred embodiment, this is accomplished via a user interface screen or menu which appears on the display monitor of the imaging system. This menu contains a list of the activated configured remote devices for the particular imaging system. Next to each device name is a virtual toggle switch (defaulted to OFF). In the OFF state, the DICOM task will be configured in accordance with the first Attribute Control File which is compliant with a first communications standard, e.g., the DICOM 98 standard. If the user toggles the switch for a particular device to ON (this can be done on a per device basis), then the DICOM task will be configured in accordance with the second Attribute Control File which is compliant with a second communications standard, e.g., the DICOM 99 standard, and in particular, the IHE (Integrating Healthcare Enterprises) technical framework employing the DICOM 99 standard. These files are installed on the imaging machine. By toggling switches on an Active Device Configuration menu, the user is able to tell the system which Attribute Control File to use (to configure a DICOM task) for which remote device.
In accordance with the preferred embodiment, each DICOM task has two Attribute Control Files associated therewith, each Attribute Control File identifying the attributes and attribute tags required for compatibility with respective communications standards. As in the case of the DICOM 98 and DICOM 99 standards, one communications standard has different attribute requirements than the other. The first Attribute Control File is designed to conform to the first communications standard, while the second Attribute Control File is designed to conform to the second communications standard. In addition, the first Attribute Control File is programmable to allow the corresponding DICOM task to be configured to be compliant with a particular remote device within the framework of the first communications standard, i.e., the DICOM 98 standard.
As presently embodied, the second communications standard is the IHE technical framework, which utilizes two existing standards: DICOM 99 on the modality side and HL-7 on the information side. The purpose of the IHE project is to organize the utilization of existing standards to create better synergy among information, imaging, and peripheral medical computer systems. Without this initiative, imaging vendors could be compliant in the DICOM standard, but still pass different information. Further, expected behavior not defined by the standards are properly described by the IHE standards. This will help an institution when trying to create a complete computerized networked solution made up of varying vendors. If all vendors subscribe to the IHE technical framework, then the institution can be guaranteed that all systems will work together properly and as expected. Since the second Attribute Control File is intended to contain all of the attribute tags required by the IHE technical framework and since the first Attribute Control File is programmable to allow customization by the field service engineer, the second Attribute Control File does not need to be, but certainly could be, programmable to allow customization by the field service engineer. At a minimum, the second Attribute Control File should be upgradeable to reflect changes in the IHE technical framework.
The invention disclosed herein greatly simplifies the DICOM compatibility problems associated with the new DICOM 99 attribute tags (potentially problematic tags for remote devices that cannot handle them) by associating them with a term (i.e., xe2x80x9cIHExe2x80x9d) more familiar to the institution and allowing the user to simply turn those tags off or on without really having to know what tags are new and what tags are old. It is a simple one-switch effort on a per device basis.
Although the disclosure of the preferred embodiment makes reference to the DICOM 98 and DICOM 99 communications standards, it will be readily appreciated by persons skilled in the art that the invention has application in any imaging system which must comply with two distinct communications standards. The invention disclosed herein relates generally to imaging systems which acquire images that need to be sent to remotely located devices via a network. Although the disclosed preferred embodiment is an ultrasound imaging system, the invention has application in other types of imaging systems. Furthermore, although the preferred embodiment of the invention communicates with remote devices using the DICOM standard, the invention has application with any digital image communications standard or protocol.